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Note to Reader 


1. For an overview of the study, it is recommended that the 
reader begin with Part I, "Purpose and Scope", followed by 


Part V, "Summary and Conclusions." 


2. It would be useful for readers to review Part VII, "Notes 
on Terminology" before addressing the remainder of the study 
to familiarize themselves with certain study terminology and 


concepts that may be both unusual and confusing. 
3. Footnotes and Appendixes are either at the end of a 


Part, or in Part IV, at the end of each cost element. Footnotes 


for tables are on the table page itself. 
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Part I: Purpose and Scope 


Compatibility with existing ODP hardware/software 
implies IBM compatibility. This study, however, does not 
address the disadvantages or advantages of IBM architecture, 
hardware or software, either in a technical or cost sense. 
Technical and cost evaluation are more appropriately performed 
during a formal evaluation of vendor proposals submitted in 
response to an RFP. This study addresses the impact of 
compatibility on ODP management and resources; the fact 
that the common architecture is IBM is not significant. 

This ODP internal impact is primarily due to factors such as 
the greater possibility for resource sharing with a common 
ODP architecture. Generally speaking, it is difficult to 


structure an RFP to include these factors. (1) 


It should be emphasized at the outset that this study 
addresses only the compatibility of the CIA SAFE system with 
ODP. A counterpart study on the value of DIA compatibility 
is in progress. Since SAFE ADPE will be common to both CIA 
and DIA, until the two studies are reconciled, no final 


"value of compatibility" can be derived. 


It is hoped that this study will serve to clarify the 
value of compatibility in terms of aggregate cost savings 
and other qualitative factors. This value must only be 


interpreted, however, in terms of an overall assessment that 
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includes procurement issues, technical, management/administrative 
and cost factors. For example, there may be an overriding 
technical reason for preferring one architecture over the 

others or the cost savings associated with a specific architecture 
May overwhelm any cost savings associated with compatibility.. 

The required overall assessment should, in most cases, take 

the form of a formal evaluation of vendor responses to an 


RFP. 


Examples of external factors explicitly excluded from 
this study which are often associated with the common architecture 
concept but in fact are attributes of a specific architecture 
(e.g., TBM) are: the potential for multi-sourcing and the 
availability of a very large commercial software base. This 
study makes no effort to evaluate the truth of these assertions 
or their impact. Such an evaluation, if appropriate, should 
be done as part of an overall evaluation, since the factors 


described are not related to compatibility. 


Finally, no effort has been made to evaluate the impact 
of Federal Information Processing Standards 60-63, which 
deal with I/O interface standards and have the practical 
impact of restricting most future procurements to mainframes 
that function with IBM-compatible peripherals. These standards, 
which come into effect during FY-80, may have a profound 


impact on the SAFE 
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ADPE procurement. The existence of these standards is an 
external factor and not associated with compatibility. Lt 
should be noted, however, that an IBM-compatible architecture 
will in fact meet the standard. It is not known at this time 
whether vendors of other mainframe architectures will have 
offerings that also meet the standards. 

How, in a practical sense, should the results of this 
study and its DIA equivalent be used? First, a unified ODP- 
CSPO-DIA position on the "value of compatibility" must be 
arrived at. This value will have to be assessed as to whether 
it is an overriding factor or just another factor to be 
considered in the formal procurement evaluation. This decision 
as to whether it is an overriding factor is a critical one. 
Such a decision would be made if it were believed that the 
value of compatibility was so significant that the outcome 
of the procurement was, in effect, predetermined (at least 
as far as architecture). The purpose of restricting the pro- 
curement explicitly would be to avoid "exercising the market- 
place." Of course, any restriction of the procurement would 
have to be made only after the responsible individuals con- 
vinced themselves that the case for the value of compatibility 
was absolutely oompelling and it would be unrealistic to 
believe that a high score in other evaluation criteria could 
overwhelm the compatibility weight. The above is definitely 


not meant as an argument for restriction of the procurement. 
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In fact, in a procurement such as the SAFE ADPE, which is in 


the nature of a new start, a very strong case indeed would be 
required to restrict the procurement. It must be remembered 
that the government routinely is expected to absorb very 

heavy costs in the interests of open competition in the ADPE 
arena (e.g., software conversion costs, in particular assembly 
language code). 

If a decision is made that the value of compatibility is 
not overriding, or that issues of procurement policy require 
that the procurement not restrict architectures, a method must 
be developed to "fold-in" the value of compatibility to the 
formal proposal evaluation. This will be a part of the overall 
SAFE ADPE procurement stretegy which is currently under 


development. 


(1) Suggestions on how to directly integrate at least some 
ODP internal factors into the RFP are provided in the detailed 


discussion (see Part IV). 
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Part II. Introduction 

ODP operates two major centers in the Headquarters 
complex: the Ruffing Center and the Special Center. Both 
centers are compatible in terms of hardware and system 
software. It is commonly believed within ODP that this’ 
compatibility between centers permits significant cost savings 
and provides management and operational benefits. The CIA 
SAFE computer center is scheduled for IOC in 1982. It is 
reasonable to ask what cost sayings and benefits could be 
achieved if SAFE were required to be compatible with the 
existing ODP centers. The purpose of this study is to examine 
the issue of cost-savings and benefits associated with SAFE 
compatibility. Our goal would be to quantify the value of 
SAFE compatibility in dollar terms for use in the evaluation 
scheme of the SAFE hardware and system software competitive 
procurement. The final derived "value of compatibility" 
could be, for example, added to the cost of any proposed system 
that was non-compatible in an analogous manner to the handling 
of software conversion costs in proposal evaluation. It is 
believed that this approach is fair to both the marketplace, 
in that it permits an unrestricted procurement, and fair to 
the government, in that real-world government costs and 


benefits are evaluated. 


In the next section, an attempt is made to arrive ata 


definition of compatibility that is suitable for our purposes. 
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The remainder of the study is devoted to a discussion of the 
impact of compatibility and an attempt to measure this impact 


in dollar terms, where possible. 


Definition of Compatibility 

The aspects of compatibility we are concerned with are 
those that enhance the possibility that ODP Ruffing Center 
and Special Center resources (staff and equipment) are shareable 
by SAFE at little or no additional cost. Examples of the 
support ODP resources could provide that would be facilitated 
by compatibility are operating system support, processing 
support and trained staff both on a regular and reserve (i.e., 
backup) basis. Another possibility for benefits is from 


consolidated procurement of compatible hardware and software. 


Four levels of compatibility have been identified that 
would affect the opportunities for resource sharing. These 
are defined below in order of increasing compatibility. It 
should be noted that these four compatibility states represent 
a vastly oversimplified view of a compability situation that 
has a multitude of possibilities. 

1.  Non-Compatibility (N/C) 

Non-compatibility is defined as SAFE mainframes 

that are not IBM-compatible (i.e., non-compatible 
mainframes are therefore those that do not utilize 
the IBM 370 series instruction repertoire). With 


one minor exception, ODP mainframes in the Ruffing and 
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23 Hardware Compatibility (H/C) 


SAFE mainframes are IBM-compatible, do utilize 
the IBM 370 series instruction repertoire as ODP 
mainframes in the Ruffing and Special Centers do. 
as Hardware/Software Compatibility (H/S/C) 
SAFE mainframes are IBM-compatible and SAFE 
operating system software is an ODP-supported 
IBM operating system (currently, MVS or VM). 
4. Full Compatibility (F/C) 
SAFE mainframes are IBM-compatible; operating 
system software is ODP-supported (i.e., currently 
MVS or VM) and the SAFE primary DBMS is an 


ODP-supported DBMS (currently GIM II). 


In both the system software and DBMS areas, 
the requirement for ODP support is significant, 
since the depth of support is a measure of the 
available ODP resources that might be utilized by 
SAPE. For example, if SAFE mainframes are H/S 
compatible with ODP it would be generally possible 
to run the same DBMS on either. Some benefits 
would accrue from this possibility (e.g., in the 


backup area). However, if ODP does not support 


the particular DBMS, no in-place system programming 
or system engineering expertise would routinely be 
available. Thus to obtain maximum benefits from 
operating system and DBMS compatibility, supported 


systems are required. 
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The above compatibility definitions referred to SAFE 
mainframes as if they all were to have similar hardware and 
software configurations. This will not necessarily be the 
case. The proposed SAFE system architecture involves two 
levels of processors: the so-called maxi and midi levels. 
Even assuming that all hardware and software is similar and 
likewise all midi H/S is similar, compatibility questions 
become very complicated. It is possible to have maxi com- 
patibility with ODP mainframes and midi non-compatibility; 
maxi and midi compatibility with ODP mainframes (though of 
varying types -- e.g., different O/S or DBMS); or less likely, 


maxi non~compatibility and midi compatibility. 


In short, even in our simplified model of the compatibility 
situation, there are sixteen possibilities. The most likely 


possibilities are summarized below. (2) 


N/C N/C 
H/C H/C 
H/S/C H/S/C 
H/C H/S/C 
H/S/C H/C 


Each one of these situations presents different opportunities 


for resource sharing. 
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Footnotes to Part II 


(1) The TADS computer, an IBM 360/67, is the minor deviation 


(2) There are sixteen possibilities, since there are four 
compatibility situations each, for both the maxi and midi. 
Five states may be singled out as most likely under the 
following assumptions: 1) the SAFE maxi and midi may be 
required to have a homogeneous architecture to minimize the 
complexity of software development. 2) full compatibility 
for either the midi or maxi is unlikely due to GIM II's 


apparent non-suitability for SAFE. 


2 
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Part III: © Overview of the Study 


The Compatibility Issue 


This study attempts to estimate the impact, in cost terms, 
of a non~-compatible CIA SAFE system. Non-compatibility, as used 
herein, refers to a SAFE system that is not hardware (and there- 
fore not software) compatible with the ODP Ruffing and Special 
Centers. This is equivalent to a SAFE system that is not con- 
figured with IBM or IBM plug-compatible mainframes. (It should 
be noted that the SAFE mainframe architecture has not been 
selected at this writing and it is the purpose of this study to 
assist in the selection by clarifying the value of compatibility. 

Part I, "Purpose and Scope" expands upon this point.) 

As discussed in Part II, "Introduction," the compatibility 
issue gets very complicated very quickly as there are numerous 
possibilities caused by two levels of SAFE mainframe hardware 
and the several possibilities in the area of operating system 
software. For the purposes of this impact analysis, costs will 
be derived that quantify the difference in impact to ODP between: 
Homogeneous SAFE Midi & Maxi H/S 
H/S Compatible SAFE: IBM or IBM Plug-Compatible Hardware 


ODP-supported Operating System 


( 
( 
( 
( (i.e., VM or MVS) 


and 


Non-Compatible SAFE: ( SAFE Midi & Maxi are not IBM or 
IBM Plug-Compatible 
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In order to simplify the analysis,the assumption has been 
made that SAFE will fall into one of the categories above. 
Mixed modes have therefore been ignored (e.g., heterogeneous 
midi and maxi; non-ODP-supported O/S, etc.). This assumption 


is believed to be realistic. 


The Model 

In thinking about the impact of a non-compatible archi- 
tecture on an organization such as ODP, we have chosen to 
organize our thoughts around a specific "model." From the 
viewpoint of this model, a non-compatible SAFE architecture 
implies a “barrier” within ODP. This architecture barrier 
impedes the transfer of resources between SAFE and other ODP 
centers, as well as the related problem: the transfer of 
workload. (Management can either transfer resources -- people, 
hardware, software, etc. -- to the “work," or transfer the 
workload to the resources -- i.e., load sharing.) Costs must 
be incurred in overcoming the architecture barrier or a reduced 
capability must be accepted. Examples are systems programming 
support and overflow load sharing in a non-compatible environ-- 
ment. The former can be overcome by providing separate system 
programming support in the SAFE center (i.e., for the non-IBM 
O/S). The latter workload transfer problem would cause a non- 


compatible ODP to, for example, live with a batch backlog 
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(i.e., a reduced capability as compared to a compatible 
environment). 
Table III summarizes the resource/workload categories 
and the detailed areas of non-compatibility impact. Part 
IV assesses the impact in each area with an attempt to develop 


a cost estimate, where feasible. 


The Cost Impact 


Costs are derived over the systems life and not the 
architecture life. The rationale behind this choice is 
discussed in Appendix III. Though the use of evaluated costs 
(often referred to as discounted or present value costs) is 
technically correct for combining costs distributed over time, 
this approach has not been followed. This decision has been 
made because of the time involved in developing these a 
and our belief that the costs developed in this study are 
useful as rough measures of aggregate impact only. If the 
costs are to be used directly in proposal evaluation, dis- 
counted costs will be required. Costs have therefore been 
assumed in constant 1979 dollars. Occasionally, costs were 


most conveniently developed in FY-79 dollars. For all practical 


purposes, FY-79 dollars are assumed equal to 1979 dollars. 


(1) Actually, the time involved in updating these costs, as it 
is assumed that after discussion, revisions to the costs estimates 


will inevitably be required. 
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TABLE III 


Summary Sheet: Cost of Non-Compatibility 
with Existing ODP Hardware/Software 


Resource/Workload Impact 
Category . (Cost Element No) 


A. Management Expertise A~i: Increased Management Complexity and 
Program Risk 


B. People B-l: Impact on Personnel Management 
B-2: Increased Vendor System Training 
B-3: Additional Personnel Requirements 


C. Hardware/Software C-1: Limitations on Reconfiguration & 
Reutilization 


C-2: Unavailability of Emergency and 
Limited Disaster Hardware Backup 


C-3: Consolidated Procurement 


C-4: Software Exchange Limitations 


{ Continued) 
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Resource/Workload 
Category 


D. Workload 
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TABLE IIL 


Summary Sheet: Cost of Non-Compatibility 
with Existing ODP Hardware/Software (con't) 


Impact 
(Cost Element No.) 


D: Technical Barriers to Load Sharing (see following) 
D-1: Routine Production Lead Sharing 
D-2: Routine Development Load Sharing 
D-3: Backup Load Sharing (see following) 
D-3{a): Overflow Load Sharing 


D-3(>): Disaster Backup 
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Appendix III: Systems Life vs. Architecture Life 


An important distinction can be made between systems 
life and architecture life. Systems life, as conventionally 
used, refers to the useful life of hardware in support of a 
specific service. Architecture life goes beyond system life 
and represents the estimated time until a total system 
reprocurement (i.e., hardware and software) will be performed. 
Typically, at the end of system life, a hardware upgrade 
is performed and the replaced hardware is reutilized; soft- 
ware, however, is not totally redesigned. The end of archi- 
tecture life, as defined herein, implies that software requires a 
"bottom-up" redesign due to system deficiencies, the increased 
cost of maintenance and/or evolving requirements. A competitive 
reprocurement of the complete system opens up the possibility 
of a change in architecture. 
For the CIA SAFE project, a 7 year systems life beyond I0Oc 
is assumed. For the architecture life of SAFE, a fifteen (15) 
year estimate, beyond IOC, appears reasonable. In SAFE procure- 
ments, the systems life estimate will be used. This is because 
it is judged unrealistic to estimate most costs and benefits beyond 
the limited systems life. For example, major hardware upgrade 
costs, mainframe costs, and other support costs are exceptionally 
difficult to estimate in out-years. Vendors are reluctant to make 
proposals over extended time periods. Systems life, however, (e.g., 


to the first major mainframe upgrade) appears a reasonable period 


OF tIRS Red Fit Hats WOH I/0INS -RIRNHA-GHBSaRESTHOUEZIDOTS been 
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historically willing to bid over this limited time period. 
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Part IV. Value of Compatibility: Cost and Impact Breakdown 
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COsT OF NON-COMPATIBILITY | 


Cost Element No: A-1 


Cost Element : Increased Management Complexity and 
Program Risk 


Cost Qualitative Factor 


Evaluated Cost ;: - 


Discussion 

A non-compatible SAFE system would inyolve an architecture 
unfamiliar to the majority of ODP Management. In addition to 
the "new" architecture aspects, ODP would become a multi- 
architecture operation which by itself increases management 
complexity. 

This added complexity in a multi-architecture environment 
is related to what is, in effect, a barrier inherent in archi- 
tecture differences. This barrier inhibits or even prevents 
the transfer of resources (i.e., people and hardware/software) 
between SAFE and other ODP centers. The alternative to resource 
transfers, the transfer of workload, is generally speaking also 
impractical in a multi-architecture environment. 

These constraints make management more difficult. Resources 
assignd to one architecture are generally not shared, limiting 
the usefulness of any resource "Slack" or "cushion" available 
in the office. This requires better planning by management 


than would otherwise be required. The margin for error is 
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smaller and the risks are therefore higher. These risks are 
diminished capability and a resulting impact on mission 


effectiveness, 
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COST OF NON-COMPATIBILITY _ 


Cost Element No: Boi 
Cost Element : Impact on Personnel Management 
Cost 2 Qualitative Factor 


Evaluated Cost 


Discussion: 

SAFE non-compatibility would present both advantages and 
disadvantages in the personnel management area. 

ro) | Advantages. 

With a non-compatible SAFE, ODP would be supporting at 
least two distinct mainfirame architectures. This would provide 
new challenges and opportunities for ODP personnel. Breadth 
of experience is an asset for a data processing professional. 

It can also be conjectured that a multi-architecture 
environment expands our recruiting pool in that 1) prospective 
employees with experience in either the ODP- or SAFE-supported 
architecture could more quickly contribute and therefore more 
easily be cost-justified and 2) the breadth of experience 
available in a multi-architecture environment could be a 
recruiting incentive. 

° Disadvantages. 

In a multi-architecture environment transfer of personnel 
between SAFE and ODP Processing would be a more complicated 


problem than with a single architecture: 
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a. 


Considerable training would he required (see Cost 
Element B-2) 

Productivity of transferred personnel would initially _ 
be lower even after training 

The pool of experienced people will be smaller. 

A reluctance of management to transfer personnel to 
work with a different architecture because of the drop 
in productivity. This constrains utilization of personnel 
resources. 

A reluctance of personnel to transfer to a position 
that requires familiarity with a different architecture 


(i.e., "fear of the unknown"). 
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Cost Element No: B-2 
Cost Element : Increased Vendor System Training 
Cost : $440K 


Evaluated Cost :. - 


Discussion 

If SAFE is non-compatible with ODP, SAFE personnel, who 
will primarily come from the current ODP organization, will 
require intensive training on SAFE hardware and operating 
systems (i.e., the vendor system), in addition to SAFE appli- 
cations training. 

Table B-2 provides an estimate of minimum SAFE Government 
professional/technical personnel post-I0C. The figures are 
a modification of current CSPO estimates. (1) 

Other personnel requiring SAFE vendor systems training 
will be ODP backup personnel. These ODP personnel are cross- 
trained in SAFE hardware and software and primarily have other 
ODP functions but serve as SAFE backup when required. The 


number of ODP backup personnel is also estimated in Table B-2. 


Analysis 

The Cost of Non-Compatibility is the cost of training in 
the new vendor hardware and operating system(s), SAFE personnel 
and ODP backup and their replacements over the systems life. 
Total personnel to be trained pre-IOC is 60 (44 SAFE and 16 
backup, from Table B-2). An estimated 10 percent or 6 new 


personnel annually will require similar training throughout 
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the systems life (2) 


The vendor system training required is estimated as 20 
days/trainee ( = 160 hours/trainee). The direct cost of this 
training is further estimated as $100/day. The total direct 
training cost is therefore $2000/trainee. 

During training, the employee is assumed compensated at 
the current FY-79 ODP average annual salary of $21.37K, a 
prorated over 160 hours of training (of 2080 available annually) 
and adjusted for 40% government burden. oe 
Employee compensation during training = 

($21.37K X 1.4 X 160/2080) = $2.3K 

The Cost of Non-Compatibility in the area of vendor system 
training is the total training cost, which is: (No. of Trainees) X 
(Direct Training Cost + Employee Compensation during Training). 
For Pre-IOC training, this cost is: 

60 X ($2K + $2.3K) = $258K 
For training of replacements during the systems life (7 years), 
the cost is: 

7X 6 X ($2K + $2.3K)= $181K 


Therefore, the estimated systems life cost for vendor systems 


training is ($258K + $181K) = $439K 
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Footnotes to Cost Element No. B-2 


(1) Reference 2 includes an estimate of CIA SAFE personnel 
requirements. It indicates that 36 CIA SAFE "operations" 
personnel will be required, but excludes some (unspecified) 
software and engineering support to be done jointly with DIA. 
An additional 8 personnel ("Enhanced SAFE Staff") have been 
included in Table B-2. The functions of these additional 
personnel,though not directly addressed in Reference 2, appear 
to be most suitable for performance by government personnel. 
The resulting staff of 44 is considered for our purpose a 
minimum government level. 

It should not be inferred that the 44 personnel will be 
slotted in the SAFE Operations Group or even ODP (e.g. secure 
personnel may be from the Office of Security). The 44 personnel, 
in fact, exceed the 33 ODP slots estimated for the SAFE 
Operations Group (See Reference 3) and the overall staffing 
estimate in the Consolidated SAFE Requirements Document (CSRD), 
Reference l. 

(2) Assumes 20 percent replacement rate of which half or 
10 percent require vendor system training. It is assumed the 
other 10 percent has vendor systems expertise through prior 


training or experience. 
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(3) From C/P&BG/MS/ODP. 
(4) 26% Standard Fringe Benefit Factors with 11% (est.) 


CIA G&A, see Reference 5, pages 24 & 44-49, Rounded to 40%. 


e 
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Table B-2 


Estimated Minimum SAFE Government Personnel Requirements (Post-I0C) 


Job Category No. of Govt. Professional/Technical Personnel 


Enhanced 
SAFE Operations Group (1) 


ODP Ba ckup eas: 


oan ten nen AER et He RN errr 


Performance Mgmt, 


jFacilities/Config, Mgmt. 


meee rate a OE A Ne ttre once 


aintenance 


Systems Mnt. (Vendor) 


Administration 


Project Office Admin. 


Database Admin. 


etre emma en rec Re mr NR i neem A 


ns nn EAN Yb REN LAP 


ye pt Senet er eee re 


User Training 


System Training 


(ech, Writing 
TOTAL 


Enhanced SAFE Opevations Crous eydenel obs: 
Possibly Se DR HOP : sy: BR AbbeRabNseote in t oe ee 


are believed reasonable extensions of SAFE personnel requirements. 


Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6 


COST OF NON-COMPATIBILITY | 


Cost Element No: B-3 
Cost Element : Additional Personnel Requirements 
Cost : $4090K 


Evaluated Cost : - 


Discussion 

In an H/S compatible environment, certain ODP Processing 
personnel could provide common support to both Processing and 
SAFE; these personnel are referred to as shareable. With a 
non-compatible SAFE, the common support of shareable personnel 
is not available and an increase in SAFE personnel requirements 
would result. 

Shareable Personnel resources are defined as those ODP 
professional or technical personnel (staff or contractor) 
supporting on-going ODP Processing activities whose work is 
directly applicable to SAFE at little or no additional cost. 
An example would be systems programming support in an H/S 
compatible environment. 

The architecture barrier present with a non-compatible 
SAFE interferes with the transfer of the work product of these 
Shareable Personnel. To make up for this loss, an equivalent 
number of personnel must be included as part of overall SAFE 
personnel requirements. It should be emphasized that these 


personnel are not the full complement of SAFE staff but are 
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additional to those that would otherwise be required in an 
H/S compatible environment. Additional Personnel for 
Non-Compatible SAFE are therefore defined as the estimated 
ODP staff or contractor personnel required to support a non- 
compatible SAFE minus estimated ODP personnel required to 
support an H/S compatible SAFE. In this analysis, the difference, 
i.e., the number of Additional Personnel for Non-Compatibility 
is assumed equal to the Shareable Personnel in an H/S compatible 
environment. 
Analysis 

Table B-3 presents an estimate of the Additional Personnel 
for Non-Compatibility (= Shareable Personnel in an H/S compatible 
environment) by job category. An estimated total of 13 addi- 
tional personnel are required annually in a non-compatible 
environment throughout the systems life. In fact, it may be 
argued that these additional personnel will be required through- 
out the architecture life. (Architecture life, as used herein, 
extends beyond systems life, to the time of system total re- 
procurement or redesign: i.e., an estimated 15 eee 
Since the goal of this analysis is to develop assessments 
suitable for use in proposal evaluation, the cost estimate is 
limited to the systems life (7 years). 

In Appendix B-3, an average annual cost for the 13 addi- 
tional personnel is computed as $584K. This represents the 
cost of funding 13 positions at an approximate average govern- 


ment-contractor salary. Over the 7 year systems life, this is 
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$4090K (undiscounted). Thus the estimated cost of non- 


compatibility in the area of personnel requirements is 


$4090K (1979 dollars). 


(1) See Appendix III, Part III: "Architecture Life vs. 


Systems Life." 
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Table B-3: Estimate of Additional Personnel for Non-Compatible SAFE 


————— 
Pa 


Additional Personnel 
for Non-Compatible SAFE 


Comments 


(Comments below refer to difference in personnel requirements 
between Non-Compatible SAFE and H/S Compatible SAFE) 


(=Shareable Personnel 
w/ H/S Compatible SAFE 


Title 


Operations 


Op t 3 i 
perations Technical Specialists required for SPD/OD interface 


(Already available for current IBM 0/S"'s) 
Additional person for new architecture. 

(Large body of expertise in ED/SEB on IRM H/S) 
Additional Config. Mgr. for new_architecture. 


Performance Mgmt. 


Facilities/Config. Mgmt. 


Maintenance 


Hardware Mnt. IBM~compatible vendor interfaces being managed by existing staff. 


Additional staff required for new vendor interfaces associated w/ 


Software Mnt, - new architecture. 


Systems Mnt. (Vendor) SPD currently performs this function for IBM 0/S's; new 


systems programming gro ould be required. 
DBMS Mnet. “ ee ead ote 


SAFE Mnt. 


Administration 


Additional person Tor new architecture. (Large body of expertise 
ED/SEB on IBM hardware; consolidated planning/procurement possible 
in H/S Compatible environment). 


n 


Project Office Admin. 
Database Admin. 
Security 


ae 


Revelopment 


Systems Eng. (Planning) 


Applications Dev. 


Training/Documentation 


User Training 


System Training 


Tech. Writing 


TOTAL 


*Compatibility 1s not judged to have an impact on personnel 
requirements. 
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Cost of Non-Compatibility: Cost Element B-3 


APPENDIX B-3 


Cost of Additional Personnel 


Required to Support a Non-Compatible SAFE 


TABLE 1: Computation of AverageSalary of Additional Personnel 


Avg. 
Salary 


FY-79 Burdened 
Govt. Salary|Govt. Salary 
(1) 


Contractor 
Salary 
(3) 


Govt. Grade 


Ss ae 4 
44.6K 


52.9% 


(1) Assuming Step 5 


(2) 40% burden added to FY-79 Govt. Salary 
(3) 100% burden added to FY-79 Govt. Salary 


(4) Average of Burdened Govt. Salary and Contractor Salary 


#00933R000500020001-6 


SP Pema Pe ae 
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Cost of Non-Compatibility: Cost Element B-3 
Appendix B-3 (continued) 


Table 2: Estimated Annual Cost of Additional Personnel 


Annual Est. FY-1979 
Job Category Additional | Equivalent | Avg. Salary/ Annual 
Personnel Govt. Grade Person Cost 


No. Title 

A.l Geerati ons 
A.2 | Perf. Mgmt 
A.3 Leama pres 
B.1 | Hdwre. Mnt. 


B.2a} Softwre. Mnt. 
(Systems) 


D.1 | Sys. Eng. 


GRAND TOTAL $584K (1) 


(1) Annual cost of 14 additional personnel, in FY-79 dollars. 
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COST OF NON-COMPATIBILITY 


Cost Element No: C-l 


Cost Element : Limitations on Reconfiguration and 
Reutilization 
Cost : $490K 


Evaluated Cost : 


Discussion 

If the SAFE Center were non-compatible with other ODP 
centers, the transfer of hardware between centers would generally 
be impossible. Reconfiguration between centers includes the 
temporary transfer of equipment for test purposes and the per- 
manent re-allocation of equipment to satisfy higher priority 
requirements, improve performance and balance workload. 
Reutilization occurs when the requirement in one center for 
a hardware item no longer exists (i.e., equipment reaches the 
end of its systems life). Opportunities for reutilization 
would then be explored within ODP (and throughout CIA) prior 
to release to GSA as excess to agency needs. Reutilization 
is really a special form of reconfiguration in which the equip- 
ment has reached the end of its systems life due to capacity 
limitations or technological obsolescence. 

Reconfiguration and reutilization (R/R) are currently 
routine activities within ODP. R/R is distinguished from 
emergency and (limited and full) disaster eee that 


R/R is for long-term service improvement or configuration test. 
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Analysis 

A rough bound on the value of reutilization with an H/S 
compatible SAFE may be computed under the following assumptions: 

(1) SAFE Center hardware will not be reutilized (in another 
ODP center) until the end of systems life (by definition). 

(2) Unlike the other ODP centers, the SAFE Center will 
support a single high performance service; equipment that has 
reached the end of its systems life in the Ruffing or Special 
Centers will, generally speaking, not be suitable for SAFE 
operations for performance reasons. 

(3) Excluding workstations and printers, an estimate of 
the purchase price of the CIA SAFE IOC configuration is 
$6023K (1979 dollars). (See Appendix C-1). 

At the end of the systems life, it is estimated that the 
residual value of the SAFE hardware is 10% of the initial pur= 
chase price: i.e., 10% of $6023K or $602K. Furthermore, it 
is assumed that at the end of systems life, 50% of the SAFE 
equipment (by value) can be reutilized. Therefore, a rough 
estimate of the value of reutilization is 50% of $602K or 
approximately $300K. ey 

A similar approach may be used to bound the value of re- 
configuration. The following assumptions are made in this 


case: 


(1) SAFE being a single high priority/high performance 
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service will not divert any hardware prior to the end of 
systems life for use in other ODP centers (and thereby suffer 
degradation in SAFE performance). 

(2) At the midpoint of systems life, SAFE hardware (ex- 
cluding workstations and printers) is valued at 50% of the 
purchase price or $3012K. It is furthermore eesaied that 25% of 
the SAFE equipment (by value) is swapped for higher performance 
Ruffing or Special Center equipment. This swapping (i.e., 
reconfiguration) results in a 25% increase in SAFE equipment 
capacity and no significant degradation in ODP service per- 
formance (as distinguished from equipment performance). 

In line with the assumptions above, at the midpoint of 
systems life, reconfiguration provides a 25% increase in 
equipment value for 25% of the equipment, or: .25 X .25 X 


$3012K = $188K. Thus the value of reconfiguration may be 


roughly estimated as $188K. 

This admittedly is a crude approach that assumes no loss 
of value in the ODP centers receiving presumably lower per- 
formance equipment. se 

The net value of reconfiguration and reutilization is 


$188K + $300K = $488K (1979 dollars). This figure should be 


taken as a rough guide only. 
(1) Theoretically, residual value is a government-wide (not 


agency-specific) concept. Therefore, SAFE hardware will have 


an estimated $602K residual value independent of whether 
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reutilization in ODP or the Agency is possible: i.e., the 
value accrues to the government not to an agency. (for example, 
in a procurement evaluation, residual value is computed for all. 
hardware irrespective of the real prospects for reutilization 
in an agency.) However, the approach followed above, though 
conceptually imperfect, does reflect the real-world benefit to 
ODP and the Agency. 

(2) Another major problem with this approach is that it fails 
to properly account for the interaction between reconfiguration 
and reutilization. A more detailed analysis was judged beyond 


the scope of this study. 
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Appendix C-1 (a) 


"Estimated Purchase Price of IBM-Compatible 
CIA SAFE IOC Configuration (exc. Workstations 


and Printers) 


The IOC configuration assumes a User Terminal Support 
subsystem sized for approximately 600 workstations; the cost 
of these 600 workstations (and associated printers) is 
excluded from the estimate. Three approaches are available 
for making this estimate: 

Approach 1: Use of the Marketplace 

Proposals received in response to SAFE ADPE RFP would he 
examined. The lowest purchase price for a configuration that 
utilized IBM-compatible hardware would be selected. 

Approach IIT: Use of the IBM GSA Schedule 

The IBM GAS ADP Schedule would be used to price out the 
roc configuration. 


Approach III: Use of the Configuration STATINT 


Purchase Price 


ee «ees (Reference 4(b)) prices out a sample 
SAFE I0C configuration using 2:3" 2-. Table 


1, Appendix C-1(b) is the basic cost data. The CIA SAFE I0c 
(1) 
configuration purchase price is computed to be: $6023K. 


Approach I uses competitively-derived prices and is 
actually ideal. Prior to proposal evaluation, however, it is 


(2) 


clearly not possible. 
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Approach II, use of the IBM GSA ADP Schedule Price List 


provides an effective "ceiling" on a true competitively- 
derived cost. This approach will not be used because of the 
time involved in developing an IBM-compatible configuration. 
If more time were available, this could be pursued. 
Approach III uses the readily available PE con- STATINTL 
figuration costs as an approximation of the cost for the 
comparable IBM-compatible configuration. For convenience, this 


approach will actually be used, Therefore, 


The estimated cost of an IBM-compatible SAFE IOC 
configuration, for the purposes of this analysis is: $6023K 


(1979 dollars). 


(1) Ignoring the DIA subsystem costs, the workstation and 
printer costs, and using only half of the User Terminal Support 
subsystem (i.e., UTSC--Item 7) cost. 

(2) This approach is a candidate for use in the actual RFP 
evaluation if the value of IBM-compatibility is actually 


"folded-in" to the evaluation. 
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Appendix C-1(b) 
Estimated Purchase Price and Systems Life Cost of 


CIA SAFE IOC Configuration 


Table 1: Purchase Price and Done Maintenance of CIA 
SAFE IOC Configuration. (1) 


SAFE 

ADPE Purchase - Monthly 
item Amount Maintenance 
L ~ SCMC $665.2K $ 2,523 

7 = UTSC x .5 912.6K 3,682 

8 - MAPC 694.3K 2,712 

9 - DCM 1 3403.5K 12,662 
12. =“ DEM. 2 347.1K 1,329 

TOTAL $6023K $22,908 


The systems life cost of the CIA SAFE I0C configuration 
(excluding workstations and printers) may be approximated by 
assuming a seven year (84 month) systems life for the entire 
Ioc configuration. Therefore, the (undiscounted) systems life 
cost is: 

Systems Life Cost = Purchase Price + Systems Life (months) 

x Monthly Maintenance 


$6023K + 84 x 22.9K 


$7947K (1979 dollars) 
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Footnote to Appendex C-1(b) 
STATINTL 


(1) From MB sare Cost Proposal, page 5-3 (Reference 4(a)). 


RE 2 2:202r- configuration; excludes DIA, workstations 


and printers and .5 x UTSC cost (UTSC subsystem is downsized 
50% to reflect contract vice proposal workstation quantities; 


UTSC configuration costed will support 600 terminals.) 
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COST OF NON-COMPATIBILITY 


Cost Element No: C-2 

Cost Element : Unavailability of Emergency and Limited 
Disaster Hardware Backup 

Cost : S40K 

Evaluated Cost : - 

Discussion 

An emergency situation for our purposes is defined as an 
item of SAFE hardware rendered inoperative for a prolonged 
period of time. The problem is due to a routine malfunction 
and the delay is due to troubleshooting or parts supply 
difficulties. 

A limited disaster as used herein is defined as a small 
number of SAFE hardware items rendered inoperative due to 
fire, flood, explosion, physical damage, etc. Routine equipment 
malfunction is excluded. The limited disaster may leave the 
SAFE system operative, but in a degraded mode. The equipment 
affected will generally require extensive refurbishment or 
replacement. In a limited disaster situation it is possible 
that hardware could be used from another ODP center. The 
equipment transfer could generally be performed sooner tha a 
vendor replacement could be supplied. 

A limited disaster is distinguished from a full disaster 
where a major portion of the SAFE Center is damaged and the 


SAFE system is inoperative (see Cost Element D-3 (b) ) 
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The above definition also applies to the other ODP 
centers with SAFE hardware being used for backup. A non- 
compatible SAFE renders emergency and limited disaster hard- 
ware backup impossible. 

Analysis 

The following assumptions will be made in order to 
estimate the cost impact of the unavailability of emergency 
and disaster backup: 

(1) Because SAFE is a high priority/high performance single 
service, SAFE hardware will not be available for extended 
periods to provide backup for the ODP Ruffing and Special 
Centers, 

(2) With an H/S compatible SAFE, the extensive hardware 
in the Ruffing and Special Centers would be a candidate for . 
SAFE emergency and limited disaster backup. 

(3) The SAFE backup is assumed required for 10% of the 
Toc configuration (by value) for 5% of the systems life (4 out 
of 84 months). 

The value of the backup required may then be estimated as 

% of the systems life cost of the 10% of the system peas ns 
backup. An estimate of the IBM-compatible CIA SAFE IOC con- 
figuration systems life cost is provided in Appendix C-1(b): 
i.e., $7947K. The value of the backup provided by ODP Pro- 


cessing may be computed by pro-rating this systems life cost: 
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Value of SAFE Emergency and 


-05 x .1 x $7947K 


Limited Disaster Backup 


S$40K (1979 dollars) 
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COST OF NON-COMPATIBILITY — 


Cost Element No : C-3 
Cost Element : Consolidated Procurement 


Cost 


No Cost Impact or Impact can be Evaluated 
in Procurement 


Evaluated Cost ; oo 


Discussion 

An H/S compatible SAFE opens up the possibility of ODP- 
wide consolidated procurement of hardware, software and main- 
tenance services. Consolidated procurement may permit 
government cost saving through a. favorable vendor pricing 
structure stemming from economies of scale. The larger single 
vendor hardware/software base possible in an H/S compatible 
environment increases government leverage, which may lead to 
improved vendor maintenance performance. Another possible 
benefit of a larger single vendor base (as ecnmared with a 
multi-vendor base that would generally occur in non-compatible 
environment) is savings in the total floor space required for 
maintenance support and a reduction in total vendor maintenance 
personnel (with a savings in attendant security clearance pro- 
cessing costs and other government administrative support costs). 
Thus an H/S compatible SAFE may lead to: 

1) ODP-wide consolidated hardware procurement encompassing 


larger quantities of equipment than separate procurements 
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as would generally be required in a multi-architecture 

environment. 

2) Consolidated maintenance contracts covering larger 

quantities of equipment than would be the case in a 

multi-architecture environment. Miscellaneous resource 

savings (space, etc.) due to the possibilities of a large 

Single vendor base and improved leverage over the 

Maintenance vendor. 

3) Consolidated software procurements covering the pur- 

chase, licensing and maintenance of multiple copies of 

software. 
Analysis 

Assessing the government cost savings in the above situations 
is a complex problem that is Significantly related to procurement 
policy and practice. ODP experience indicates that vendor 
pricing has not been overly sensitive to volume except for 
some hardware procurement situations and some software licensing 
agreements. 

Typically, vendor GSA ADP Schedules show purchase and 
maintenance prices on a "per box" basis and software licensing 
and maintenance on a "per CPU" patie ae assumptions 
about savings from vendor volume discounts are probably true 
within a specific vendor's pricing structure; however, between 


(2) 


vendors, actual price comparisons are required. 
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That being the case, loss of consolidated procurement, 
through non-compatibility, will have an unknown cost impact. 
Assuming cost benefits to be associated with consolidated pro- 
curement would be an example of "prejudging the marketplace." 
The SAFE procurement itself can be used to determine vendor 
pricing practices by requiring vendors to propose the hardware/ 
software and maintenance services required over the systems 
life. No marketplace inferences need or should be made 
external to the initial SAFE Beseveaes 

In a non-compatible environment, volume discounts through 
consolidated procurements and maintenance, and benefits -due 
to a large single vendor base would, generally speaking, not 
be seeeioies The impact of the loss of these savings and 
benefits is assessed in more detail below: 

1) Consolidated Hardware Procurements. Consolidated 

hardware procurements require H/S compatibility and 

common requirements. The SAFE hardware covered in 

the existing SAFE contract will be procured independent _ 

of ODP Ruffing Center and Special Center Pee ea 

Presuming H/S compatibility and common requirements, 

subsequent procurements, as yet unspecified, could be 

consolidated. These procurements would most likely 
involve peripherals, primarily disks and teste 


Currently quantities are unknown on both the SAFE 


and ODP Processing sides. 
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As discussed earlier, though favorable pricing for a 
consolidated procurement is a reasonable assumption, 

it is far from a certainty. Use of anticipated cost 
saving from unspecified future consolidated procure- 
ment as a factor in an RFP evaluation or procurement 
decision would be a questionable sel ean 

2) Consolidated Hardware Maintenance. Consolidated 
maintenance requires an additional constraint to 

H/S compatibility: identical vendors. While identical 
vendors are likely in the mainframe area (i.e., ODP 


STATINTL 


has several CPU's from two of the major IBM-compatible 


vendors, MB, it is tess certain in the 


peripheral area. ODP currently has a policy of OEM 
aaieeataeee 7 OEM's have not, as mentioned earlier, 
provided volume discounts, but priced on a "per box" 
basis. Maintenance for the initial SAFE hardware will 

be procured in the RFP. Maintenance prices will there- 
fore be evaluated ee Maintenance for equipment 
subsequently procured might be less expensive if equipment 
were from an Sachse vendor, but as this argument woul be 
questionable for restricting competition in a procurement, 
it should not be considered as a factor in valuing the 
impact of non-compatibility. 

In a similar vein to the above, maintenance vendor space 


requirements can be evaluated (i.e., costed)directly in 
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the initial SAFE RFP. Procurement practice would require 
the space provided not be unduly limited, which would 
result in restricting the competition to in-house vendors. 
Arguments similar to the above discussion on consolidated 
maintenance pricing for follow-on SAFE procurement would 
dictate that hypothetical maintenance vendor space savings 
in future procurements not be considered an impact of non- 
compatibility. Procurement practice also requires, except 
in unusual circumstances, that security clearance and 
administrative support costs should not be allowed to 
restrict competition. 

An H/S compatible SAFE may lead to a large single vendor 
base which improves government "leverage" over the vendor 
and may lead to improved hardware availability. Though 

the above is "logical" and "common sense," it is purely 
Beeawuea cua should not be used as a basis for govern- 
ment decisions. Hardware availability requirements should 
be specified directly in the RFP and vendor capabilities 
evaluated, with penalties for non-performance. 

3). Consolidated Software Procurement and Maintenance. 
Most vendor software is priced on a "per CPU" basis except 
where tightly-coupled networks are involved (e.g., JES3). 
Certain types of independent vendor software, however, are 
discounted when multiple copies are ordered. System soft- 
ware initially procured for SAFE will probably be evaluated in 
the RFP. In an H/S compatible environment, subsequent pro- 


curements of software for SAFE and other ODP centers from 
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independent software vendors and from the mainframe hard- 

ware vendors might reflect discounts due to copies running 
on other ODP CPU's. As in the discussion of consolidated 

hardware and consolidated maintenance above, the benefits 

are largely hypothetical and will not be considered in 


(11) 
evaluating the impact of compatibility. 
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Footnotes for Cost Element No. C=-3 


(1) Tightly-coupled networks (like JES3) often are an 
exception to "per CPU" licensing; the network is priced as 
one CUP (though possibly containing several CPU's, 

(2) That is, four units of vendor X's equipment are not 
necessarily cheaper than two units of vendor X's equipment 
plus two units of vendor Y's. It depends, obviously, on the 
cost of vendor Y's equipment. 

(3) The potential for Saving on procurements subsequent ‘to 
the initial SAFE procurement is a more complicated issue and 
is discussed in the following sections. 

(4) This ignores the possibility of a multi-architecture con- 
solidated procurement; e.g9., vendors with multi-architecture 
product lines or third party maintenance or leasing firms 
could respond to multi-architecture consolidated procurements. 
(5) With the possible exception of CRT terminals, 

(6) Note that consolidated terminal procurement may be possible 
even without H/S compatibility. 

(7) It should be noted that Computer System Division at NPIC 
is a Univac-compatible operation. Therefore, e.g., if SAFE 
were Univac~compatible, there exists the possibility of 
consolidated procurements between NPIC and SAFE. (ODP has 
already procured CRT terminals in a consolidated procurement 


with NPIC.) 
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(8) This is currently under study within ODP Processing. 

(9) The possibility of a vendor providing a maintenance price 
reduction on ODP Processing hardware as well as SAFE hardware, 
and therefore not subject to evaluation in the SAFE RFP is 

judged small, primarily because it would be in the best interests 
of the vendor to reflect all discounts in the RFP. 

(10) We know of no study that demonstrates a correlation between 
the size of a vendor base in an installation and equipment 
availability. 

(11) For example,due the H/S compatibility and a multiple copies 
requirement in ODP, an independent software vendor might provide 
discounts from the single copy price of the software. However, 
another hardware equipment vendor might provide a similar package 
free, oar the vendor might provide different versions which 
execute on different architectures and therefore discounts might 


be available for multiple copies irrespective of architecture, etc. 
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COST OF NON-COMPATIBILITY 


Cost Element No: C-4 
Cost Element : Software Exchange Limitations 
Cost : $470K 


Evaluated Cost : - 


Discussion 

With a H/S compatible architecture, government-owned 
software could be exchanged between SAFE and other ODP centers. 
In a non-compatible environment software exchange would be either 
impossible or require an expensive conversion. Bpdeatehe dS 
owned software suitable for exchange may be divided into two 
categories: 
1) Contractor-developed SAFE software for which ODP Ruffing 
or Special Center requirements exist; 
2) ODP-, user-, or contractor-developed software executing 


in the Ruffing or Special Center that satisfies a SAFE 


requirement. 


An example of the former category is SAFE text search 
software. ODP personnel have indicated that a DDO text search 
requirement similar to SAFE's is under discussion. An example 
of software in the latter category might be GIM II for structured 
DBMS gee eed ak an ge oa model developed by the 


Office of Economic Research. 
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In the first category, it is estimated that 3.53% of SAFE 
contractor-developed software will be exchanged with other ODP 
ete Introduction of this SAFE software will occur over 
the seven year systems life at an estimated rate of -2% annually. 
In a non-compatible environment, this software cannot simply be 
exchanged but must be either independently developed or converted. 
The estimated cost of independent development of the exchanged 
software would be: 

$313K = 3.5% of $8950K (cost of contractor-developed 

software) = 
Assuming 50% of the exchanged software (by value) requires 
development (i.e., $157K) and the remaining software is suitable 
for conversion at 50% of the development cost (i.e., .5 x .5 x 
$313K = $78K), the effective value of exchanged software is: 
$157K + $78K = $235K. 

Considering the second category of software exchange: it 
is estimated that 3.5% of the SAFE software scheduled for con- 
tractor development will be available from ODP in a compatible 


(4) 


architecture environment. The resulting saving will occur 


pre-I0C. This equates to a $235K estimated savings (see above 
computation). During systems life, the hard SAFE requirement 
for additional ODP-developed software is judged small. ODP 
mainframes will be accessible to SAFE users.through the SAFE-ODP 


communications link. Therefore, stand-alone ODP software 
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packages (e.g., econometric models) will be available to SAFE 
users independent of SAFE architecture. 

The total value of software exchange is the sum of the 
value in the two categories discussed above. The final estimate 


is therefore $470K (1979 dollars). 
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Footnotes to Cost Element No. C-4 


(1) A distinction is made between licensed software and govern- 
ment-owned because the former generally incurs a separate cost 
when run on additional mainframes and, if available, can be 
procured irrespective of arthitecture compatibility. 

(2) GIM II is government-owned and therefore free; with an N/C 
architecture an alternative would be procurement of a comparable 
vendor DBMS package. 

(3) An N/C architecture would require a conversion. 

(4) The estimated 3.5% rate of software exchange is based on 

1) low rate of ODP-or user-developed software exchanged between 
the ODP Ruffing and Special Center, 2) historical lack of success 
in fostering exchange in the federal government (e.g., poor 
performance of Federal Software Exchange Program). 

(5) See Appendix C-4 for the estimated cost of contractor-developed 


SAFE software. 
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Appendix C-4: Estimated Cost of Contractor-Developed 
: SAFE Software 


The approximate cost of contractor-developed SAFE software 
is computed by first estimating the number of Lines of Source Code, 
converting to Project Man-Hours and then using an estimated Dollars 
per Man~Hour figure to generate the software development cost. 

The stepwise procedure follows: 

Step 1: Computation of the Number of Lines of Contractor- 
developed Source Code (i.e., higher order language 
(HOL) or assembly language (ALC)): 
The contractor has provided an estimate of 445K 
deliverable, executable machine instructions mae 
We assume that the DEMI's are generated 50% (222.5K) 
from HOL source code and 50% (222.5K) from ALC source 
code. Assuming a conservative 2 DEMI's per line of HOL 
source, this implies 111.25K lines of HOL source (i.e., 
222.5K DEMI's + 2 lines HOL source/DEMI) and 222.5K 
lines of ALC source for a total of 333.75K Lines of 
Source Code. 

Step 2: Computation of Number of Man-Hours of Total Project 

| ee Using 173.3 Man-Hours/Man-Month (i.e., 2080 
Hours/Year + 12)and 150 Lines of Source Code per Man- 
Month of Total Project re ee compute the Man- 
Hours of Total Project Effort: 333.75K Lines Source 
Code X (173.3 + 150) Man-Hours/Line of Source Code = 


385.6K Man-Hours. 
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Step 3: Final Computation of Estimated Cost of COnEreccor™ 
developed Software: 


Estimated Cost of 
Contractor-developed 
Software 


_ 385.6K Man-Hours x $23.2/Man-Hour 
Total Project. Effort (3) 


$8950K (1979 dollars) 
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Footnotes to Appendix C-4 
STATINTL 


(1) BR estinate from Proposal, Vol. I, pages 1-19 (Reference 
; a 


(2) A lower quartile total effort productivity estimate from 


Walston and Felix, IBM Systems Journal, "A Method of 
Programming Measurement and Estimation," 1977, (Reference 
Bx 


(3) Derived from proprietary data: 


Total Project Labor Dollars + Total Project Labor Hours 


STATINTL 
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COST OF NON-COMPATIBILITY 


Cost Element No. : D 

Cost Element : Technical Barriers to Load Sharing 

Cost : $500K + Other Factors (see sub-elements) 
Evaluated Cost : 

Discussion 

Load Sharing may be divided into several categories. Other 
cost elements are associated with the cost of transferring 
resources (people, hardware/software) between non-compatible 
architectures. Load Sharing is an alternate approach (i.e., 
transferring the workload) but it too is generally rendered 
impractical by non-compatibility. 

Several categories of load sharing may be defined: 

D-1. Routine Production Load Sharing. 

This category implies SAFE production software is explicitly 
designed to run in the ODP Ruffing Center. Software in this 
category is not considered part of the SAFE workload (i.e., 

SAFE is not necessarily sized to process it). In fact, SAFE 
may not be able to process this software at all. (This would 

be the case with a non-compatible architecture.) This concept 
also encompasses the reverse situation: ODP production software 
designed to run in the SAFE Center. 

D-2. Routine Development Load Sharing 

SAFE systems and/or applications software development (post- 


Toc) is routinely performed on ODP mainframes. This activity 
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is primarily prime-shift activity associated with maintenance 
and enhancements. 

D-3. Backup Load Sharing 

Backup Load Sharing is subdivided into two major sub- 
categories: Overflow and Disaster. 

D-3(a) Overflow Load Sharing 

Overflow load sharing implies that under peak load 

conditions (e.g., backlog) workload (primarily batch) 

could be shifted between SAFE and other ODP centers. 

D-3(b) Disaster Backup 

Disaster backup implies the capability to transfer 

critical workload between ODP centers in the event of the 

unavailability of a major service. Unavailability of 
service as defined herein is considered to be long-term 
and due to a power outage, fire, flood, etc. 

The impact of SAFE non-compatibility on the various cate- 
gories of load sharing is discussed in the following cost sub-_ 
elements. The costs presented above are the aggregate costs 
associated with the load sharing categories (i.e., the sum of 


the load sharing sub-element costs that follow). 
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COST OF NON-COMPATIBILITY 


Cost Sub-element No.: D-1 

Cost Sub-element : Routine Production Load Sharing 
Cost : No Impact 

Evaluated Cost : 7 

Discussion 


Batch processing support of SAFE in the Ruffing Center 
would be more straightforward in an H/S compatible environment. 
The SAFE gana Ceara. includes only one reference to offline 
batch processing requiring Ruffing Center support. This is in 
the SAFE Management Information System (MIS) area. SAFE is 
designed as an almost exclusively online system; e.g., database 
update is on an online continuous basis. Therefore, batch pro- 
cessing requirements and, in particular, offline batch require- 
ments, are envisioned as small. Any benefits in the batch 
processing area associated with H/S compatibility would 
correspondingly be small. 

Two additional factors minimize this cost sub-element: 

1. The SAFE dual maxi processors in off-peak periods 
(primarily night) could no doubt provide a substantial batch 
processing capability within SAFE. 

Zi Any routine offline batch processing hard requirement 
could be satisfied by applications programs specifically 
designed to run on Ruffing Center mainframes. This approach 
would also permit ODP applications programmers to support SAFE 


without substantial special SAFE architecture training. 
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Because of adequate non-prime shift Ruffing Center 
capability, the reverse situation (i.e., routine ODP production 


assigned to the SAFE Center) should not be necessary. 


(1) 


Consolidated SAFE Requirements Document (Reference 1) 
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COST OF NON-COMPATIBILITY 


Cost Sub-element No: D-2 


Cost Sub-element : Routine Development Load Sharing 

Cost : No Impact/Impact can be Evaluated in 
Procurement 

Evaluated Cost : oo 


Discussion 

With an H/S compatible SAFE, ODP Ruffing Center systems 
(e.g., VM) could be used for prime-shift SAFE development 
post-I0C, (primarily systems and applications maintenance and 
enhancements). With a non-compatible SAFE, development of 
higher-order language (HOL) programs for SAFE is technically 
feasible on ODP systems, though clearly inefficient. - 

The proposed SAFE architecture has two levels of main- 
frames: so-called midi and maxi. At least one of the less 
expensive midi processors will be procured for backup and 
therefore could generally be used as a prime-shift development 
machine. If the maxi and midi are homogeneous (i.e., compatible 
in hardware and software), use of the backup midi should meet 
system-wide development requirements. If the maxi and midi 
are not compatible, a separate, probably scaled-down version 
of the maxi might be required for prime-shift development. 

If a prime-shift development machine was not available 
(either through use of the midi in a homogeneous maxi-midi 


environment or through use of Ruffing Center mainframes), the 
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vendor could be required to propose an additional development 
mainframe, sized to support a government specified development 
load. Thus this cost sub-element could be handled directly 

in the procurement and not require an explicit government 
estimate of the cost of a development machine. 

Recent CSPO analysis has indicated a significant cost 
saving associated with a homogeneous maxi-midi environment. 
Assuming homogeneity, because of the availability of the 
backup for development, non-compatibility is estimated in 
this category as having no cost impact. If homogeneity is 
not the case, this cost impact can be evaluated, as discussed 


above, directly in the SAFE ADPE procurement. 


(1) Development could be accomplished through the use of 
emulators, cross-compilers or the ODP language most similar 

to the SAFE HOL. These surrogate approaches are poor sub- 
stitutes for development using a system compatible with SAFE. 
Under the surrogate approach, extensive “live" SAFE time would 
be required for further development, conversion, system 


integration, test. etc. 
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COST OF NON-COMPATIBILITY 


Cost Sub-element No: D-3(a) 


Cost Sub-element : Backup Load Sharing (Overflow Load 
Sharing) 

Cost : $250K 

Evaluated Cost 2 

Discussion 


Overflow load sharing would, in certain circumstances, 
be possible with an H/S compatible SAFE; i.e., under peak load 
conditions workload (primarily batch) could be shifted among 
ODP centers. oe 

In a practical sense, however, the requirement for over- 
flow load sharing between SAFE and other ODP centers is judged 
small. SAFE is almost exclusively an online system; its 
unique system architecture (as distinguished from mainframe 
architecture) would render infeasible the off-loading of SAFE 
online tasks. In addition, the SAFE batch workload is very 
limited. SAFE processing capacity should be more than adequate 
to handle SAFE batch workload during non-prime time. i 

During prime-time, there will be little excess SAFE capa- 
city for processing ODP overflow batch or online workload. ” 
In non-prime time, the available capacity in the SAFE Center 
should increase. However, the same is true in the Ruffing and 
Special ania rate the requirement for overflow load sharing 


should be minimal. In addition, the Special Center can and 


occasionally does serve as an outlet for Ruffing Center overflow. 
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Overflow load sharing, only possible in an H/S compatible 
environment, is therefore judged of small value to ODP. 

An.estimate of the value of overflow load sharing is 5% 
of the systems life cost of an IBM-compatible SAFE dual maxi 
processor (i.e., the Document/Catalog Management/Text Search 
Management/Index Search Management Subsystem). The underlying 
assumption is that 5% of an IBM-compatible dual maxi pesuedeer 
would be used to process Ruffing Center overflow (e.g., 10% of 
processor capacity during the non-prime shift). An estimate 
of $4926K is developed in Appendix D-3(a) for the systems life 
cost of the dual maxi processor configuration. 

Therefore, the value of compatibility for over load- 


sharing is estimated as 5% of $4926K or $246K (1979 dollars). 


(1) This discussion of the potential for load sharing 
intentionally ignores security issues inherent in inter-center 
load sharing. 

(2) The batch workload identified at this time (e.g., the SAFE 
Management Information System) is not time-sensitive. SAFE will 
be sized to handle prime-time online loads. During non-prime 
time excess capacity for batch processing should routinely be 


available. 
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(3) As in the reverse situation, the routine off-loading of 
Ruffing Center online overflow (e.g., selective GIMS data- 
bases) would be a difficult technical task. 

(4) Utilizing this non-prime time capacity might require re- 
configuring ("downsizing") ODP online services; e.g., trans~ 
ferring VM from the IBM 3033 to the IBM 370/158. 


(5) Special Center overflow is negligible. 
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Appendix D-3(a): Estimate of the Cost of an IBM-compatible 
Dual Maxi Processor Configuration, Suitable 
for Backup Load Sharing 


In the SAFE System, the Document/Catalog Management/Text 
Search Management/Index Search Management (DCM/TSM/ISM) Sub~ 
system is planned as a dual maxi processor. If it were IBM- 
compatible, as are the ODP Ruffing and Special Centers, there 
would be the possibility of backup load Shara Vins this 
appendix, an approximate systems life cost for an IBM- 
compatible dual maxi processor is developed. The value of 
IBM-compatibility for backup load sharing is estimated as the 
percentage of an IBM-compatible dual maxi processor subsystem 
resource used applied to the cost of the subsystem. 

Table 1 details the dual maxi processor configuration. 
Three approaches to estimating the cost ofan IBM-compatible 
dual maxi processor configuration are now described: 

fe) Approach I: Use of the Marketplace. 

Proposals received in response to SAFE ADPE RFP 
would be examined. The dual maxi processor con- 
figuration with the lowest overall evaluated cost 
that utilized IBM-compatible hardware would be 
selected. 

(o} Approach II: Use of the IBM GSA Schedule 

The IBM GSA ADP Schedule Price List would be used 


to cost out the dual maxi processor configuration 
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fe) Approach III: Use of Univac Configuration Cost 
The Univac dual maxi processor configuration is costed 
out in thd cost Proposal (Reference 4(b)). Table. 
1 (attached) from the proposal summarizes the Univac 
configuration cost. The estimate is approximately 
$3750K. The maintenance cost for the configuration is 
$14K/month over the systems life (pg. 5.-3, BE cost 
Proposal, Reference 4(b)). Total cost over the systems 
life (7 years) is $4926K. 

Approach I uses competitively-derived costs and is actually 
ideal. Prior to proposal evaluation, however, it is clearly 
not Per ie. 

Approach II, use of the IBM GSA ADP Schedule Price List 
provides an effective "ceiling" on a true competitively-derived 
cost. This approach will not be used because of the time in- 
volved in developing a complete IBM-compatible configuration. 

If more time were available this could be pursued. 

Approach III uses the readily available Univac configuration 
costs as an approximation of the cost for the comparable IBM- 
compatible configuration. For convenience, this approach will 


be followed. Therefore, 


The estimated cost of an IBM-compatible dual maxi processor 


configuration is = $4926K (1979 dollars). 
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TABLE 1. Dual Maxi Processor Configuration and Univac 
Implementation Cost * 


1.1.1.1.7 DCM/ADPE MAXI, DUAL PROCESSOR, 4M BYTES 


BASIS: A UNIVAC 1100/82 DUAL PROCESSOR CONFIGURATION WITH BOTH PROCESSORS SHARING 4M BYTES OF MEMORY. PLUG 


COMPATIBLE DISK CONTROLLERS ARE FROM INTERSCIENCE CORPORATION AND DISKS ARE STORAGE TECHMOLOGY 
DUAL 800M BYTE UNITS. 


ARCHITECTURE 
DESCRIPTION REPORT 
ary. 


. PROCESSOR COMPONENTS 


. TAPE CONTROLLER 
. TAPE ORIVES 

. CARD READER 

. LINE PRINTER 


. DISK SUBSYSTEM-CONTROLLERS AND 
SHARED PROCESSOR I/F 4+6=10 


. DISK SUBSYSTEM DISK DRIVES WITH (26+23)=66 
DUAL ACCESS AT 300 Ma 15 AT 2x600 MA 


(1) REOUNOANT UNIT TO IMPROVE AVAILABILITY 
(2) REQUIRED FOR DEVELOPMENT AND BY MANUFACTURER FOR SUPPORT 


UNIT EXTENDED 
wes PART NO. NAME VENDOR _PRice(3) Quantity PRICE 
W171 3032-91 PROCESSOR UNIVAS 1,216,268 1 1,218,288 
1911171 3032-00 PROCESSOR EXPANSION UNIVAG 458,050 :] 468,60 
9111971 2033-23 {OU EXPANSION UNIVAC 203,119 1 203,119 
119971 1923-6) (0 CHANNEL EXPANSION UNIVAG 7,205 2 18,610 
349979 F 1058-01 WORD CHANNEL MODULE UNIVAG 40,856 4 162,228 
119971 F 2350-89 MEMORY EXPANSION UNIVAC 180,600 4 180,000 
999171 F3137-00 REMOTE CONTROL PANEL UNIVAC 785 4 788 
111171 2626-00 SUBSYSTEM AVAILABILITY UNIT UNIVAG 68,520 1 59,520 
111171 8508.08 MOTOR ALTERNATOR UNIVAC 16,500 1 16,500 
111172, 6017-¢0 TAPE CONTROL UNIVAC 21,420 1 21,420 
111172 Foeae.ga SIMULTANEOUS OPERATION UNIVAC 16,004 1 18,084 
119972 F 0826-00 800 BF! UNIVAC 4,320 2 8,640 
419972 FOR25-00 DUAL CHANNEL UNIVAC 3,312 2 6624 
VWW172 0862.04 TAPE DRIVE UNIVAC 16,824 2 33,053 
WIZ F 1319-00 DUAL ACCESS UNIVAC 1,838 2 3,672 
117172 C 1809.02 INTERFACE 6017 UNIVAC w/c 2 te) 
W172 FQ037-04 OUAL DENSITY UNIVAC 1,838 2 3,672 
1111723 071602 CARD READER (W/CTL) UNIVAC 14,828 4 19,628 
111174 0776-02 PRINTER (W/CTL} UNIVAC 3,610 1 35,010 
111174 F2218-09 PRINTER CARTRIDGE UNIVAC 1,080 1 1,000 
V1175 4600 DISK CONTROL INTERSCI 57,880 19 578,500 
W175 SP) SHARED PROC INTERFACE INTERSC! 3,80 10 38,200 
FV4975 935082 DISK ORIVE (2x600MB) $fc 42,449 16 638,736 
VVV175 BELO OUAL PORT STtc O41 bh 14,116 


TOTAL $3,760,674 


(3) LIST PRICE LESS 26% DISCOUNT FOR UNIVAC UNITS 


STATINTL 


Figure 5, 3-1 Traceability OCM/TSM ADPE 


: * Fro SAFE Proposal, Vol. II, "Cost," dated 16 March 1979, 
(SA -1002-3/79) 
5-53 
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Footnotes to Appendix D-3(a): 


(1) See Cost Element D, "Technical Barrier to Load Sharing," 
for a definition of backup load sharing. 
(2) This approach is a candidate for use in the RFP evaluation 


if the value of IBM-compatibility is "folded-in" to the evaluation. 
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that both centers were rendered inoperative an H/S compatible 
SAFE would be the only in-house backup. 

During non-prime shift an H/S compatible SAFE could process 
Agency batch workload in the event of a disaster. Only limited 
prime-shift SAFE processing capacity, however, would be avail- 
able. ODP online systems such as GIM II and VM could, in theory, 
be brought up under an H/S compatible SAFE. If SAFE were not 
accessible from general-purpose ODP eavahae a disaster 
Situation, available SAFE terminals could be used for critical 
tasks. 

The related problem is the use of the Ruffing and Special 
Centers for disaster backup to SAFE. Because of the uniqueness 
of SAFE system architecture (as distinguished from mainframe 
architecture), it appears technically infeasible to back up 
SAFE online functions in the Ruffing or Special ta 
It is possible that special purpose backup software could be 
developed to provide a limited subset of SAFE capabilities 
in the Ruffing cele ae would require an unknown but 
significant development effort. There would probably be some 
advantage if the centers were H/S compatible in developing 
special purpose software. However, it is probably true that 
special purpose software could be developed even with different 
architectures. Without the required development activity, the 


value of the Ruffing Center as a significant SAFE backup is 


judged small. 
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COST OF NON-COMPATIBILITY 


Cost Sub-element No. : D=-3(b) 


Cost Sub-element : Backup Load Sharing (Disaster Backup) 
Cost : $250K 

Evaluated Cost a 

Discussion 


Disaster backup would be possible in certain circumstances 
with an H/S compatible see aes the assumption of a major 
catastrophe in the Ruffing or Special Center, batch workload 
could be processed by SAFE during non-prime shift. It is also 
possible that with an appropriate development effort, ODP on- 
line systems (e.g., GIM II, VM) could also be brought up on a 
SAFE processor during non-prime shift. In the event of a 
disaster, some SAFE functions could be supported in the Ruffing 
Center through special purpose software. This type of backup, 
however, would not be dependent on SAFE architecture. 

Currently, it is generally believed that the Ruffing and 
Special Center provide at least partial disaster backup for 
each Biicaeer “ade they are H/S compatible centers. The 
major drawbacks to successful backup would be the limited 
processing and communications capacity in the Special Center. 
The technical problem of backup for online systems would 
also be formidable. An H/S compatible SAFE would provide some 


"cushion" in a disaster situation where one or the other 


center was damaged or destroyed; or in the unlikely occurrence 
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In an H/S compatible environment, SAFE batch work could 
be supported in the Ruffing Center. The planned SAFE batch 
workload is insignificant and will consist of non-critical 
functions such as the SAFE Management Information System. The 
value of backup for SAFE batch workload is therefore considered 
minor. 

The most practical automated backup for SAFE is the DIA 
SAFE Sei ages systems will be architecturally identical. 
The practical means by which a CIA analyst could access DIA 
SAFE in the event of a CIA SAFE disaster remains to be studied. 
It is a function of the existence of link between CIA and DIA 
and the survival of a means of access to the link after the 
disaster. At a minimum, CIA analysts could be given physical 
access to DIA terminals during non-prime shift. 

The Ruffing and Special Centers are judged of minor 
value for SAFE disaster backup. Disaster backup for the 
Ruffing and Special Center would primarily be performed in 
non-prime time on the SAFE dual maxi processors (i.e., the 
Document/Catalog Management/Test Search Management/Index 
Search Management Subsystem). An upper bound, therefore, 
on the value of disaster backup is the systems life cost of 
an IBM-compatible dual maxi processor Se: 

In Appendix D-3(a) an estimate of $4926K is developed for 

the systems life cost of that configuration. It is further 
estimated that 53 of configuration resources would be required 
for disaster Basen as value of an IBM-compatible archi- 


tecture for disaster backup is therefore bounded by 5% of 
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$4926K or $246K (1979 dollars) over the systems life. 


(Ll) Security issues in a disaster backup situation will not be 
addressed in this discussion. 

(2) A formal ODP disaster plan is in preparation in ODP/MS. 
(SAFE will not be included at this time.) 

(3) The-accessibility of SAFE to general-purpose ODP terminals 
depends on whether ODP has implemented a unified bus architecture. 
(4) Because of its limited capacity, the Special Center is 
ignored from this point on as a SAFE backup. 

(5) A method for accessing incoming CIA mail from the Cable 
Dissemination System (CDS) would be required. Distribution of 
hardcopy is a possibility (though a primitive one). Note that 
use of automated access to CDS or hardcopy distribution is 
independent of SAFE architecture compatibility. 

(6) This is primarily true for SAFE private files. DIA incoming 
mail is not identical to CIA incoming mail. Alternate automated 
approaches probably utilizing Ruffing Center capabilities with 
the Cable Dissemination System (CDS) will be required to access 
CIA mail. A non-automated (and primitive) backup to private 
files such as microform backup could also be made available. 

(7) That is, an equivalent disaster backup to the SAFE dual 
maxi processor configuration could be provided by procuring an 
identical configuration and installing it in a separate "disaster" 
facility. Clearly, this is an extravagant solution. Such a 


disaster backup configuration would require an alternate primary 
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use to be cost-justified. The major portion of the cost of the 
disaster facility could therefore be charged to the primary use. 
(8) Five percent configuration resources over the 84-month 
systems life is equivalent to 8.4 months use of 50% of capacity 
(e.g., non-prime shift) for disaster backup. One would hope 
that our current safety posture would limit ODP to, for 

example, one disaster in an 84-month period with 8.4 months 


required to reconstruct and re-equip the destroyed center. 
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